[SC] Adding possibility to use float for calculations#6870
Conversation
matthias-kleiner
commented
Aug 19, 2021
matthias-kleiner
commented
- adding function to calculate the drift path for an electron
- setting default values for omega tau
- adding simple debug function
- poisson solver: cleaning + using more than 1000 phi bins
- setting default values for omega tau - adding function to calculate the drift path for an electron - adding simple debug function - poisson solver: cleaning + using more than 1000 phi bins
matthias-kleiner
requested review from
davidrohr,
shahor02 and
wiechula
as code owners
wiechula
left a comment
wiechula
left a comment
There was a problem hiding this comment.
@matthias-kleiner , there are quite some changes in the PoissonSolver. I guess you checked them against some benchmark (analytical solution)?
Hi, yes there are no differences when using doubles. When using floats there is a slight, but not significant, improvement for the resulting potential due to rounding of floats I think. But in general it looks like that the poisson solver doesnt converge when using floats instead of doubles and the calculation time for the distortions etc. is also not significantly different, which can lead sometimes to longer calculations times for floats. The difference between the resulting distortions are only a few micro meter between double and float, so it looks like at the end it doesnt really matter so much if one uses doubles or floats. But when using a really large grid the required memory can be a problem, where floats can help. And there is always the test for the Poisson solver comparing the result of the potential with the analytical potential. |
shahor02
left a comment
shahor02
left a comment
There was a problem hiding this comment.
The o2 failure is unrelated. Look fine for me (with superficial check), shall I merge it?
It seems like there is now a new error during the O2/o2-cs8 build in generateTPCCorrectionNTuple.C: |
|
@matthias-kleiner I think the error is real. Can't you try to use a forward declaration for the Vc::Memory? |
I just tried it in a Docker installation and the error is indeed real. It seems to happen when one includes Vc partially and later includes the full Vc. Reordering the include order fixed the problem in the Docker environment. However this problem on my local installation also disappears when one compiles the macro a second time after it failed once. |
|
Looks like all the tests are passing now. Can this PR then be merged? |
5 participants
